Wednesday, 06 March 2019
Triple cachestore release: Cloud, MongoDB and Cassandra
Today we present to you a trifecta of cache store releases which align to Infinispan 9.x
Cassandra Cache Store
The Cassandra cache store now implements the publishEntries/publishKeys methods.
Cloud Cache Store
The Cloud cache store uses the Apache jclouds library to store data on cloud storage providers such as Amazon’s S3, Rackspace’s Cloudfiles or any other such provider supported by JClouds. The store has been updated to Infinispan 9.x’s persistence SPI and uses jclouds 2.1.x
MongoDB Cache Store
This cache store has also been updated to the Infinispan 9.x persistence SPI.
You can get documentation and maven coordinates from our Cache Store page
Tags: release cache store
Friday, 20 October 2017
Cache Store Batch Operations
Infinispan 9.1.x introduces batch write and delete operations for cache stores. The introduction of batching should greatly improve performance when utilising write-behind cache stores, using putAll operations and committing transactions in non-transactional stores.
==
==
==
CacheWriter Interface Additions
The CacheWriter interface has been extended so that it exposes two additional methods: deleteBatch and writeBatch. For the sake of backwards compatibility a default implementation of these methods is provided, however if your cache store is able to utilise batching we strongly recommend you create your own implementations. The additional methods and docs are show below:
Configuration Changes
As each store implementations has different batching capabilities, it was necessary to introduce a max-batch-size attribute to the AbstractStoreConfiguration. This attribute defines the maximum number of entries that should be included in a single batch operation to the store. If a value less than one is provided, then the underlying store implementation should not place a upper limit on the number of entries in a batch.
Store Benchmark
To measure the impact of batch writes on Cache.putAll, we created a simple benchmark to compare the performance of Infinispan 9.1.1.Final (with batching) and 9.0.3.Final (without). The benchmark consisted of 20 threads inserting 100000 cache entries as fast as possible into a cache via putAll; with each putAll operation containing 20 cache entries and the max-batch-size of each store being set to 20. The table below shows the average time taken for each store type after the benchmark was executed three times.
| Store Type | 9.0.3.Final | 9.1.1-Final | Latency Decrease |
|---|---|---|---|
JdbcStringBasedStore | 29368ms | 2597ms | 91.12% |
JPAStore | 30798ms | 16640ms | 45.97% |
RocksDBStore | 1164ms | 209ms | 82.04% |
The benchmark results above clearly show that performance is increased dramatically when utilising batch updates at the store level.
Conclusions
Infinispan 9.1.x introduces batching capabilities to the CacheWriter interface in order to improve performance. If you currently utilise a custom cache store, we strongly recommend that you provide your own implementation of the delete and write batch methods.
If you have any feedback on the CacheWriter changes, or would like to request some new features/optimisations, let us know via the forum, issue tracker or the #infinispan channel onhttp://webchat.freenode.net/?channels=%23infinispan[ Freenode].
Tags: jdbc rocksdb jpa leveldb cache store
Monday, 05 December 2016
Composing the Infinispan Docker image
In the previous post we showed how to manipulate the Infinispan Docker container configuration at both runtime and boot time.
Before diving into multi-host Docker usage, in this post we’ll explore how to create multi-container Docker applications involving Infinispan with the help of Docker Compose.
For this we’ll look at a typical scenario of an Infinispan server backed by an Oracle database as a cache store.
All the code for this sample can be found on github.
In order to have a cache with persistence with Oracle, we need to do some configuration: configure the driver in the server, create the data source associated with the driver, and configure the cache itself with JDBC persistence.
Let’s take a look at each of those steps:
Obtaining and configuring the driver
The driver (ojdbc6.jar) should be downloaded and placed in the 'driver' folder of the sample project.
The module.xml declaration used to make it available on the server is as follows:
Configuring the Data source
The data source is configured in the "datasource" element of the server configuration file as shown below:
and inside the "datasource/drivers" element, we need to declare the driver:
Putting all together
From now on, without using Docker we’d be ready to download and install Oracle following the specific instructions for your OS, then download the Infinispan Server, edit the configuration files, copy over the driver jar, figure out how to launch the database and server, taking care not to have any port conflicts.
If it sounds too much work, it’s because it really is. Wouldn’t it be nice to have all these wired together and launched with a simple command line? Let’s take a look at the Docker way next.
Enter Docker Compose
Docker Compose is a tool part of the Docker stack to facilitate configuration, execution and management of related Docker containers.
By describing the application aspects in a single yaml file, it allows centralized control of the containers, including custom configuration and parameters, and it also allows runtime interactions with each of the exposed services.
Composing Infinispan
Our Docker Compose file to assemble the application is given below:
It contains two services:
-
one called oracle that uses the wnameless/oracle-xe-11g Docker image, with an environment variable to allow remote connections.
-
another one called *infinispan* that uses version 8.2.5.Final of the Infinispan Server image. It is launched with a custom command pointing to the changed configuration file and it also mounts two volumes in the container: one for the driver and its module.xml and another for the folder holding our server xml configuration.
Launching
To start the application, just execute
To inspect the status of the containers:
To follow the Infinispan server logs, use:
Infinispan usually starts faster than the database, and since the server waits until the database is ready (more on that later), keep an eye in the log output for "Infinispan Server 8.2.5.Final (WildFly Core 2.0.10.Final) started". After that, both Infinispan and Oracle are properly initialized.
When dealing with dependent containers in Docker based environments, it’s highly recommended to make the connection obtention between parties robust enough so that the fact that one dependency is not totally initialized doesn’t cause the whole application to fail when starting.
Although Compose does have a depends_on instruction, it simply starts the containers in the declared order but it has no means to detected when a certain container is fully initialized and ready to serve requests before launching a dependent one.
One may be tempted to simply write some glue script to detect if a certain port is open, but that does not work in practice: the network socket may be opened, but the background service could still be in transient initialization state.
The recommended solution for this it to make whoever depends on a service to retry periodically until the dependency is ready. On the Infinispan + Oracle case, we specifically configured the data source with retries to avoid failing at once if the database is not ready:
When starting the application via Compose you’ll notice that Infinispan print some WARN with connection exceptions until Oracle is available: don’t panic, this is expected!
Conclusion
Docker Compose is a powerful and easy to use tool to launch applications involving multiple containers: in this post it allowed to start Infinispan plus Oracle with custom configurations with a single command. It’s also a handy tool to have during development and testing phase of a project, specially when using/evaluating Infinispan with its many possible integrations.
Be sure to check other examples of using Docker Compose involving Infinispan: the Infinispan+Spark Twitter demo, and the Infinispan+Apache Flink demo.
Tags: compose jdbc docker persistence server modules oracle cache store
Friday, 12 August 2016
Infinispan Cloud Cachestore 8.0.1.Final
After bringing the MongoDB up-to-date a few days ago, this time it’s the turn of the Cloud Cache Store, our JClouds-based store which allows you to use any of the JClouds BlobStore providers to persist your cache data. This includes AWS S3, Google Cloud Storage, Azure Blob Storage and Rackspace Cloud Files. In a perfect world this would have been 8.0.0.Final, but Sod’s law rules, so I give you 8.0.1.Final instead :) So head on over to our store download page and try it out.
The actual configuration of the cachestore depends on the provider, so refer to the JClouds documentation. The following is a programmatic example using the "transient" provider:
And this is how you’d configure it declaratively:
This will work with any Infinispan 8.x release.
Enjoy !
Tags: release jclouds cloud storage cache store
Friday, 05 August 2016
MongoDB Cache Store 8.2.1.Final
In the storm of the persistence SPI rework that happened during Infinispan 6.0, the MongoDB cache store, among others, was left in a state of semi-abandonment for a long time.
Fortunately a few brave souls came to its rescue and have breathed new life into it so that it can be used with Infinispan 8.x
In particular I wish to thank Kurt Lehrke for doing most of the work !!!
Get it from the dedicated cache store download page.
Tags: release mongodb cache store
Wednesday, 03 February 2016
The return of the Cassandra CacheStore
Ever since we spruced up our Cache Store SPI in Infinispan 6.0, some of our "extra" cache stores have lied in a state of semi-abandonment, waiting for a kind soul with time and determination to bring them back to life. I’m glad to announce that such a kind soul, in the form of Jakub Markos, had the necessary qualities to accomplish the resurrection of the Cassandra Cache Store.
Apache Cassandra is a database with a distributed architecture which can be used to provide a virtually unlimited, horizontally scalable persistent store for Infinispan’s caches. The new Cassandra Cache Store leverages the Datastax Cassandra client driver instead of the old Thrift client approach, which makes it much more robust and reliable.
Configuration
In order to use this cache store you need to add the following dependency to your project:
You will also need to create an appropriate keyspace on your Cassandra database, or configure the auto-create-keyspace to create it automatically. The following CQL commands show how to configure the keyspace manually (using cqlsh for example):
You then need to add an appropriate cache declaration to your infinispan.xml (or whichever file you use to configure Infinispan):
It is important the the shared property on the cassandra-store element is set to true because all the Infinispan nodes will share the same Cassandra cluster.
Limitations
The cache store uses Cassandra’s own expiration mechanisms (time to live = TTL) to handle expiration of entries. Since TTL is specified in seconds, expiration lifespan and maxIdle values are handled only with seconds-precision.
In addition to this, when both lifespan and maxIdle are used, entries in the cache store effectively behave as if their lifespan = maxIdle, due to an existing bug https://issues.jboss.org/browse/ISPN-3202.
So, try it out and let us know about your experience !
Tags: persistence cassandra cache store
Monday, 14 September 2015
New Redis Cache Store Introduced in Infinispan 8
A new cache store for storage of cache data within the Redis key/value server has been introduced with Infinispan 8. This allows all storage of cache data to be stored in a centralised Redis deployment which all Infinispan clients access.
The cache store supports 3 Redis deployment topologies. They are, single server, Sentinel and cluster (Redis v3 required). Redis versions 2.8+ and 3.0+ are currently supported.
Data expiration and purging is handled via Redis itself, reducing workload from Infinispan servers to manually delete cache entries.
Topologies
Single Server
In a single server deployment, the cache store is given the location of a Redis master server with which it connects to directly to handle all data storage. Using this topology, Redis has no fault tolerance unless a custom solution is built on top of Redis. To declare a single server local cache store:
<?xml version="1.0" encoding="UTF-8"?>
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd
urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"
xmlns="urn:infinispan:config:8.0"
xmlns:redis="urn:infinispan:config:store:redis:8.0" >
<cache-container>
<local-cache>
<persistence passivation="false">
<redis-store xmlns="urn:infinispan:config:store:redis:8.0"
topology="server" socket-timeout="10000" connection-timeout="10000">
<redis-server host="server1" />
<connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />
</redis-store>
</persistence>
</local-cache>
</cache-container>
</infinispan>
Note the topology attribute is declared as server. This is needed to ensure a single server Redis topology is applied by the cache store. Only a single Redis server need be declared (only the first server will be used if multiple servers are declared) and the port will default to the Redis port 6379, but can be overridden using the port attribute. All connections are handled via a connection pool, which can optionally also test the validity of a connection on creation, lease, return from and when idling in the connection the pool.
Sentinel
The Sentinel topology relies on Redis Sentinel servers to connect to a Redis master server. Here, Infinispan connects to Redis Sentinel servers, requesting a master server name, then gets forwarded on to the correct location of the Redis master server. This topology gives resilience via Redis Sentinel, providing failure detection and automatic failover of Redis servers.
<?xml version="1.0" encoding="UTF-8"?>
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd
urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"
xmlns="urn:infinispan:config:8.0"
xmlns:redis="urn:infinispan:config:store:redis:8.0" >
<cache-container>
<local-cache>
<persistence passivation="false">
<redis-store xmlns="urn:infinispan:config:store:redis:8.0"
topology="sentinel" master-name="mymaster" socket-timeout="10000" connection-timeout="10000">
<sentinel-server host="server1" />
<sentinel-server host="server2" />
<sentinel-server host="server3" />
<connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />
</redis-store>
</persistence>
</local-cache>
</cache-container>
</infinispan>
For a Sentinel deployment, the topology attribute changes to sentinel. A master name must also be specified to select the correct Redis master required as Sentinel can monitor multiple Redis master servers. The Sentinel server is declared using a sentinel-server XML tag, which you’ll notice is different to the main Redis servers used in single server and cluster topologies. This is to allow defaulting of the Sentinel port to 26379 if not declared. At least one Sentinel server must be declared, though if you run more Sentinel servers, they should all be declared too for the benefit of failure detection of the Sentinel servers themselves.
Cluster
A cluster topology gives Infinispan the ability to connect to a Redis cluster. One or more cluster nodes are declared to infinispan (the more the better) which are then used to store all data. Redis cluster supports failure detection so if a master node in the cluster fails, a slave takes over. Redis v3 is required to run a Redis cluster.
<?xml version="1.0" encoding="UTF-8"?>
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd
urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"
xmlns="urn:infinispan:config:8.0"
xmlns:redis="urn:infinispan:config:store:redis:8.0" >
<cache-container>
<local-cache>
<persistence passivation="false">
<redis-store xmlns="urn:infinispan:config:store:redis:8.0"
topology="cluster" socket-timeout="10000" connection-timeout="10000">
<redis-server host="server1" port="6379" />
<redis-server host="server2" port="6379" />
<redis-server host="server3" port="6379" />
<connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />
</redis-store>
</persistence>
</local-cache>
</cache-container>
</infinispan>
For cluster deployments, the topology attribute must change to cluster. One or more Redis cluster nodes must be declared to access the cluster which uses the redis-server XML tag. Note that when operating a cluster, database IDs are not supported.
Multiple Cache Stores, Single Redis Deployment
Redis single server and Sentinel deployments support the option of database IDs. A database ID allows a single Redis server to host multiple individual databases, referenced via an integer ID number. This allows Infinispan to support multiple cache stores on the same Redis deployment, isolating the data between the stores. Redis cluster does not support the database ID. A database ID is defined using the database attribute on the redis-store XML tag.
<?xml version="1.0" encoding="UTF-8"?>
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd
urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"
xmlns="urn:infinispan:config:8.0"
xmlns:redis="urn:infinispan:config:store:redis:8.0" >
<cache-container>
<local-cache>
<persistence passivation="false">
<redis-store xmlns="urn:infinispan:config:store:redis:8.0"
topology="sentinel" master-name="mymaster" socket-timeout="10000" connection-timeout="10000" database="5">
<sentinel-server host="server1" />
<sentinel-server host="server2" />
<sentinel-server host="server3" />
<connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />
</redis-store>
</persistence>
</local-cache>
</cache-container>
</infinispan>
Redis Password Authentication
In order to secure access to a Redis server, a password can optionally be used in Redis. This then requires the cache store to declare the password when connecting. The password is added via a password attribute on the redis-store XML tag.
<?xml version="1.0" encoding="UTF-8"?>
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:8.0 http://www.infinispan.org/schemas/infinispan-config-8.0.xsd
urn:infinispan:config:store:redis:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-redis-config-8.0.xsd"
xmlns="urn:infinispan:config:8.0"
xmlns:redis="urn:infinispan:config:store:redis:8.0" >
<cache-container>
<local-cache>
<persistence passivation="false">
<redis-store xmlns="urn:infinispan:config:store:redis:8.0"
topology="sentinel" master-name="mymaster" socket-timeout="10000" connection-timeout="10000" password="mysecret">
<sentinel-server host="server1" />
<sentinel-server host="server2" />
<sentinel-server host="server3" />
<connection-pool min-idle="6" max-idle="10" max-total="20" min-evictable-idle-time="30000" time-between-eviction-runs="30000" />
</redis-store>
</persistence>
</local-cache>
</cache-container>
</infinispan>
Tags: release redis cache store
Tuesday, 11 August 2015
Infinispan 7.2.4.Final out including fixes for async store, Hot Rod...etc
Infinispan 7.2.4.Final is just out containing some important fixes in areas such as Hot Rod client and server, async cache store, key set iteration, as well as a Hibernate HQL parser upgrade. You can find more details about the issues fixed in our detailed release notes.
Happy hacking :)
Galder
Tags: release hotrod hql cache store
Monday, 09 September 2013
Infinispan 6.0.0.Alpha4 out with new CacheLoader/CacheWriter API!
Infinispan 6.0.0.Alpha4 is now with a few very important changes, particularly around cache stores. We’ve completely revamped the cache store/loader API to align it a bit better with JSR-107 (old CacheStore has become CacheWriter) and to simplify creation of new implementations. The new CacheLoader and CacheWriter should help implementors focus on the important operations and reduce the coding time. We’ve also created AdvancedCacheLoader and AdvancedCacheWriter in order to separate for bulk operations or purging for those implementations that wish optionally implement them. Expect a blog post from Mircea in the next few days providing many more details on this topic.
This new Infinispan version comes with other important goodies:
-
Rolling upgrades of a Infinsipan REST cluster
-
Support for Cache-Control headers for REST operations
-
Remote querying server modules and Hot Rod client update
-
REST and LevelDB stores added to Infinispan Server
-
KeyFilters can now be applied to Cache listeners
-
Allow Cache listener events to be invoked only on the primary data owner
For a complete list of features and fixes included in this release please refer to the release notes. Visit our downloads section to find the latest release and if you have any questions please check our forums, our mailing lists or ping us directly on IRC.
Cheers,
Galder
Tags: release leveldb listeners alpha rest cache store query
Tuesday, 04 June 2013
Using MongoDB as a cache store
With the 5.3 release, there is a brand new feature. I’m glad to announce that you will be able to use MongoDB as a cache store.
For those who don’t know MongoDB, it’s an open-source document oriented NoSQL database developped by 10Gen. You can more information about it on http://www.mongodb.org/.
The question you have right now, it probably, how to use it cool cache store ? Simple, as for the other cache store you have to add a loader in your Infinispan configuration file.
Here is an exemple:
If you prefer the programmatic API:
For more information about the configuration possibilities (default values, options, etc) , you can refer to the documentation page
Cheers, Guillaume Hibernate OGM & Infinispan contributor Blog / @g_scheibel
Tags: mongodb cache store
